Language/OS - Multiplatform Resource Library

home *** CD-ROM | disk | FTP | other *** search

/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / lisp / kcl / kcl.lha / doc / porting < prev next >

Wrap

Text File | 1987-06-04 | 29.5 KB | 883 lines

\(progn (defmacro set-page (name) `(setq ,name *page-number*)) (defun date () (multiple-value-bind (sec min hour date month year) (get-decoded-time) (do-string (format nil "~[January~;February~;March~;April~;May~;June~;July~;~ August~;September~;October~;November~;December~] ~ ~d, ~d" (1- month) date year)))) (defun fr () (setq *current-font* *font-roman*)) (defun fi () (setq *current-font* *font-italic*)) (defun fb () (setq *current-font* *font-bold*)) (defun fp () (setq *current-font* *font-prop*)) (defun fg () (setq *current-font* *font-big*)) (defun sm () (setq *old-left-margin* *left-margin*) (setq *left-margin* (+ (mark-column) *left-margin*))) (defun rm () (do-line-so-far) (setq *left-margin* *old-left-margin*)) (defun ra () (right-adjust)) (defun ce () (centering)) (defun br () (break-line)) (defun lm (n) (setq *left-margin* n)) (defun bd () (setq *left-margin* 100)) (defun endd () (do-line-so-far) (setq *left-margin* 0)) ) \(ra)Revised \(date) \(fg) \(ce)A Guide to Porting Kyoto Common Lisp \(fr) \(fi) \(ce)by \(fr) \(ce)Masami Hagiya \(ce)Taiichi Yuasa \(ce)Research Institute for Mathematical Sciences \(ce)Kyoto University \(ce)Kyoto, 606, Japan \(ce)Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya \(fg) Introduction \(fr) This document explains how to construct the KCL system and how to port KCL. It will also be useful for customizing the existing versions of KCL. 1. KCL/AOS Machine: \(sm)Data General's Eclipse MV series super-minicomputers (MV10000, MV8000, MV6000, and MV4000)\(rm) Operating System: \(sm)Data General's original AOS/VS (Advanced Operating System / Virtual Storage)\(rm) 2. KCL/VAX Machine: \(sm)Digital Equipment Corporation's VAX 11 series machines (VAX 11/780 and VAX 11/750)\(rm) Operating System: UNIX 4.2 bsd 3. KCL/SUN Machine: \(sm)Sun Microsystems' Sun Workstation (MC68000/MC68020 base)\(rm) Operating System: UNIX 4.2 bsd 4. KCL/UST Machine: \(sm)Sumitomo Electric Industries and Digital Computer Laboratory's personal workstation Ustation E15 (MC68000 base)\(rm) Operating System: UNIX System V (Uniplus' version) 5. KCL/DGX Machine: \(sm)Data General's Eclipse MV series super-minicomputers (MV10000, MV8000, MV6000, and MV4000)\(rm) Operating System: DGUX, Data General's native UNIX 6. KCL/3B2 Machine: \(sm)AT&T's 3B2 series workstations\(rm) Operating System: UNIX System V 7. KCL/SEQ Machine: \(sm)Sequent Balance 8000 (NS32032 base)\(rm) Operating System: UNIX 4.2 bsd 8. KCL/UTS Machine: \(sm)M Series\(rm) Operating System: UNIX System V 9. KCL/NWS Machine: \(sm)Sony NEWS (MC68020 base)\(rm) Operating System: UNIX 4.2 bsd Most of the source files of KCL are shared by these versions, but some source files are specific to some versions of KCL. In this document, we are mainly concerned with the UNIX BSD versions, and we explain how to port KCL to UNIX machines. However, this document is also helpful for those people who want to port KCL to non-UNIX machines, since it explains how to construct the KCL system in general. To port KCL to UNIX machines running under UNIX System V (or System III, XENIX, VENIX, etc.) is much more difficult than to port KCL to UNIX machines running under UNIX BSD. Particularly, the loader (fasloader) and the memory dump routine should be rewritten. Some of the standard library functions of C used in KCL may not be provided in UNIX System V. Refer to Section 11 of this document for the details. Some of the C source files of KCL contain the \(fp)#ifdef\(fr) preprocessor command followed by either of the following identifiers: \(fi)Identifier Use\(fp) ----------------------------------------- VAX \(fr)VAX/UNIX 4.2BSD\(fp) SUN \(fr)SUN-2 Releases 1.2 and 2\(fp) SUN2R3 \(fr)SUN-2 Release 3\(fp) SUN3 \(fr)SUN-3\(fp) ATT3B2 \(fr)3B2\(fp) E15 \(fr)Ustation E15 (System V)\(fp) NEWS \(fr)Sony NeWS\(fp) MC68K \(fr)MC68000\(fp) MC68020 \(fr)MC68020\(fp) NS32K \(fr)NS32032\(fp) IEEEFLOAT \(fr)IEEE floating format\(fp) UNIX \(fr)UNIX\(fp) BSD \(fr)UNIX 4.2BSD\(fp) ATT \(fr)UNIX System V\(fp) DGUX \(fr)DG/UX\(fp) AOSVS \(fr)AOS/VS\(fp) AV \(fr)Average (i.e., Non-MV) architecture\(fp) MV \(fr)ECLIPSE/MV\(fp) \(fr) Each version of KCL has a key switch by which other switches for the version are automatically defined. \(fi)Version Key Switch Other Switches\(fp) ---------------------------------------------- KCL/VAX VAX UNIX BSD AV KCL/SUN SUN UNIX BSD MC68K IEEEFLOAT AV SUN2R3 UNIX BSD MC68K IEEEFLOAT AV SUN3 UNIX BSD MC68020 IEEEFLOAT AV KCL/3B2 ATT3B2 UNIX ATT IEEEFLOAT AV KCL/UST E15 UNIX MC68K IEEEFLOAT AV KCL/DGX DGUX UNIX MV KCL/AOS AOSVS MV KCL/SEQ SEQ UNIX BSD NS32K IEEEFLOAT AV KCL/UTS S3000 UNIX ATT AV KCL/NWS NEWS UNIX BSD MC68020 IEEEFLOAT AV \(fr) Some of the Lisp source files of KCL contain the \(fp)#+\(fr) and \(fp)#-\(fr) read-macros with the feature \(fp)AOS\(fr) or \(fp)UNIX\(fr). The Common Lisp variable \(fp)*features*\(fr) is created and initialized in \(fp)c/main.c\(fr) (see below). The initial value is set according to which of the above identifiers is defined. For the UNIX versions, the symbol \(fp)UNIX\(fr) is in the features. It is desirable to make a user whose name is \(fp)kcl\(fr) and load the distribution tape directly under his home directory, and put the directory \(fp)bin\(fr) (see below) at the end of the search path, since it contains the commands for system generation. (Some of the commands assume the C shell \(fp)csh\(fr) rather than the Bourne shell \(fp)sh\(fr).) Unfortunately, the C source files of KCL use identifiers much longer than seven characters. It will take much effort to port KCL to a poor operating system in which identifiers are recognized by the first seven characters, such as the old versions of UNIX System V and System III. In this document, we first discuss how to generate the KCL system, explaining the components of KCL and how they are combined. Then, we give some hints for porting KCL to UNIX machines by discussing the hardware-dependent parts and the operating-system-dependent parts in detail. Although most of the KCL code was written by us, the authors of this \(fi)Guide\(fr), several people have contributed to the development of the current KCL. We wish to express our thanks especially to the following people. Mr. Teruo Yabe and Mr. Toshiyasu Harada of Nippon Data General helped us coding during the development of the first version of KCL. Dr. Skef Wholey at CMU allowed us to use their code for the function \(fp)rationalize\(fr). Dr. Yuuichi Ohta at the University of Tsukuba ported KCL onto Sequent Balance 8000, writing the KCL/SEQ specific code. \(fg) 1. Directories \(fr) The distribution tape of KCL source is formatted in the UNIX \(fp)tar\(fr) format. The following \(fp)tar\(fr) call will load all source files in the tape. \(fp) % tar x \(fr) The source files of KCL are stored in four directories: \(fp)h \(fr)header files \(fp)c \(fr)source files in C \(fp)lsp \(fr)source files in Lisp \(fp)cmpnew \(fr)source files of compiler in Lisp The object files of C source files are placed in the directory \(fp)o\(fr). The KCL itself is placed in the directory \(fp)unixport\(fr). This directory contains other files needed for the system generation. The directory \(fp)bin\(fr) contains the commands used in the system generation. \(fg) 2. Makefiles \(fr) Each of the directories \(fp)bin\(fr), \(fp)o\(fr), \(fp)lsp\(fr), \(fp)cmpnew\(fr), and \(fp)unixport\(fr) has a makefile in it. \(fp)bin/makefile\(fr) to prepare the commands defined in the \(fp)bin\(fr) directory \(fp)o/makefile\(fr) to compile the source files in the \(fp)c\(fr) directory \(fp)lsp/makefile\(fr) to compile the source files in the \(fp)lsp\(fr) directory \(fp)cmpnew/makefile\(fr) to compile the source files in the \(fp)cmpnew\(fr) directory \(fp)unixport/makefile\(fr) to link and initialize KCL There is another \(fp)makefile\(fr) in the KCL directory (i.e. the current working directory when you read in the source tape). This makefile does all the jobs of the above makefiles. These makefiles are intended for those users who are responsible for the maintenance of KCL/VAX or KCL/SUN at their sites. (We do not know whether these makefiles are useful when KCL is ported to yet another machine/os.) The makefiles \(fp)o/makefile\(fr) and \(fp)unixport/makefile\(fr) contain version-dependent parts, as indicated \(fp) MACHINE = SUN3 # Select 'VAX', 'SUN', 'SUN2R3', 'SUN3', 'ISI', 'SEQ', 'IBMRT', # or 'NEWS'. CHTAB = sun_chtab.s # Select 'char_table.s' or 'sun_chtab.s'. # 1) char_table.s : for VAX, SEQ and NEWS # 2) sun_chtab.s : for SUN, SUN2R3 and SUN3 # 3) isi_chtab.s : for ISI # 4) ibmrt_chtab.s: for IBMRT \(fr) in \(fp)o/makefile\(fr) and \(fp) MACHINE = SUN3 # Select 'VAX', 'SUN', 'SUN2R3', 'SUN3', 'ISI', 'SEQ', 'IBMRT', # or 'NEWS'. \(fr) in \(fp)unixport/makefile\(fr). Check these parts before using these files and, if necessary, modify them. To install KCL/VAX or KCL/SUN from the source for the first time, do the following at the KCL directory. \(fp) % su # cp h/cmpinclude.h /usr/include # exit % make % su # make install # exit % \(fr) To revise KCL, do the following at the KCL directory. \(fp) % make \(fr) \(fg) 3. Header Files \(fr) All the header files for C source files are stored in the \(fp)h\(fr) directory. The header file \(fp)include.h\(fr) is the toplevel header file; it includes other header files needed for compiling C source files. It also defines the appropriate switches from the key switch of the version. Since each C source file includes \(fp)include.h\(fr) by the preprocessor statement \(fp) #include "include.h", \(fr) there is a copy of \(fp)include.h\(fr) in the \(fp)c\(fr) directory. Including \(fp)include.h\(fr) will include \(fp)stdio.h\(fr) and \(fp)ctype.h\(fr), which are the standard include files of C. The C source files that define number functions also include \(fp)h/num_include.h\(fr) by another preprocessor statement \(fp) #include "num_include.h". \(fr) \(fp)num_include.h\(fr) is linked to the \(fp)c\(fr) directory. \(fg) 4. C Source Files \(fr) Some of the source files in the \(fp)c\(fr) directory have the suffix "\(fp).d\(fr)". These files should be preprocessed by the preprocessor called \(fp)dpp\(fr) (\(fi)D\(fr)efun \(fi)P\(fr)re\(fi)P\(fr)rocessor) before compiled by the C compiler. The source file of \(fp)dpp\(fr) (i.e., \(fp)dpp.c\(fr)) is in the \(fp)bin\(fr) directory. It should be compiled (in the \(fp)bin\(fr) directory) by \(fp) % cc -O -o dpp -DUNIX dpp.c \(fr) Or, you can use the makefile in the \(fp)bin\(fr) directory. \(fp) % cd bin % make \(fr) \(fp)dpp\(fr) is called by \(fp) % dpp \(fi)filename\(fr) This will preprocess \(fi)filename\(fp).d\(fr) and produce \(fi)filename\(fp).c\(fr). Each C source file (after preprocessed by \(fp)dpp\(fr)) is compiled by the following command. \(fp) % cc -D\(fi)name\(fp) -DMAXPAGE=\(fi)mp\(fp) -DVSSIZE=\(fi)vs\(fp) -O -c \(fi)filename\(fp).c \(fr) \(fi)name\(fr) is the key switch of the KCL version. You are recommended to invent another name for your machine. \(fi)mp\(fr) is the maximum number of pages (1 page = 2048 bytes) the KCL process will use. It does not contain the space for the stack segment, but does contain the space for the text, data, and bss. \(fi)vs\(fr) is the size of the value stack of KCL in words. The object files of the C source files should be placed in the \(fp)o\(fr) directory; move the output of the C compiler to the \(fp)o\(fr) directory. \(fp) % mv \(fi)filename\(fp).o ../o \(fr) The command \(fp)bin/ccc\(fr) does all the task; \(fp) % ccc \(fi)filename\(fr) will preprocess the source file, compile the source file and move the object file to the \(fp)o\(fr) directory. \(fi)filename\(fr) is the file name of the source file without the suffix (\(fp).c\(fr) or \(fp).d\(fr)). The values of \(fi)mp\(fr) and \(fi)vs\(fr) used in \(fp)ccc\(fr) are \(fp)16384\(fr) (32 Mbytes) and \(fp)2048\(fr) (words). The command \(fp)bin/cccall\(fr) compiles all the C source files, assembles an assembler file (see below), and places the output in the \(fp)o\(fr) directory. Or, you can use the makefile in the \(fp)o\(fr) directory. \(fp) % cd o % make \(fr) Two C source files contain \(fp)asm\(fr) statements. One is for double-word multiplication and division (\(fp)earith.c\(fr)) and another is for bit-table operation (\(fp)bitop.c\(fr)). Refer to Section 10.1. \(fg) 5. The Assembler File \(fr) There is one assembler file that should be assembled by \(fp)as\(fr). This file allocates the table of character objects (\(fp)character_table\(fr)). For the VAX and SEQ versions, it has the name \(fp)char_table.s\(fr), for the SUN, SUN2R3 and SUN3 versions \(fp)sun_chtab.s\(fr). The output should be placed in \(fp)o/char_table.o\(fr) even for \(fp)sun_chtab.s\(fr). This file only defines the symbol \(fp)_character_table\(fr) (in the data or bss segment) and allocates a space of 1024 bytes and a space of 2048 bytes before and after the symbol, respectively. This file is needed because of the pathological phenomenon that C \(fp)char\(fr)'s may sometimes be signed. \(fg) 6. Libraries \(fr) Some of the Common Lisp functions are written in Lisp (Common Lisp). They are divided into several library files in the \(fp)lsp\(fr) directory. These files have been compiled by the KCL compiler, and for each library file, the following files are prepared: \(fi)filename\(fp).lsp\(fr) Lisp source file \(fi)filename\(fp).c\(fr) translated C source file \(fi)filename\(fp).h\(fr) header file for \(fi)filename\(fp).c\(fr) \(fi)filename\(fp).data\(fr) data file in the form of text The translated C source file \(fi)filename\(fp).c\(fr) includes the header files \(fp)h/cmpinclude.h\(fr) and \(fi)filename\(fp).h\(fr). Since the header file \(fp)cmpinclude.h\(fr) is included by the preprocessor statement \(fp) #include <cmpinclude.h> \(fr) it should be moved (or linked) to the directory that stores standard include files of C (say, \(fp)/usr/include\(fr)). Each translated C source file is compiled by the following command. \(fp) % cc -O -c \(fi)filename\(fp).c \(fr) Note that the translated C source files are completely independent of the version of KCL. The data file should be attached at the end of the object file, using, say, the \(fp)cat\(fr) command. \(fp) % cat \(fi)filename\(fp).data >> \(fi)filename\(fp).o \(fr) The result should \(fi)not\(fr) be moved to the \(fp)o\(fr) directory. These object files can be loaded by the fasloader of KCL. But in this case, the text of the object will be placed in the bss segment of the KCL process and the garbage collector of KCL should take care of it. So, it is desirable to link the object with the kernel of KCL; then the text will be in the text segment and become sharable among the users. By default, all the library files of KCL are included in the KCL system (refer to Section 8). The command \(fp)bin/libccall\(fr) compiles all the translated C source files in the \(fp)lsp\(fr) directory and attaches the corresponding data files to them. Or, you can use the makefile in the \(fp)lsp\(fr) directory. \(fp) % cd lsp % make \(fr) The files \(fp)export.lsp\(fr), \(fp)autoload.lsp\(fr), and \(fp)setdoc.lsp\(fr) in the \(fp)lsp\(fr) directory should not be compiled; their Lisp sources are loaded at the system initialization. \(fp)export.lsp\(fr) exports the external symbols in the \(fp)lisp\(fr) package. Not all the external symbols in the \(fp)lisp\(fr) package are exported by \(fp)export.lsp\(fr); some are created in the initialization routines written in C and do not appear in \(fp)export.lsp\(fr). \(fp)autoload.lsp\(fr) was once used to define the autoloaded functions. Since all the library files are included in the system now, it is used to define some of the non-compiled functions, such as environment queries and editor interfaces, which do not require efficiency, but are expected to be customized. Since they are not compiled, you have only to rewrite \(fp)autoload.lsp\(fr) to modify these functions. (Refer to Section 12.) \(fp)setdoc.lsp\(fr) sets the online documentations of built-in symbols. \(fg) 7. The Compiler \(fr) The compiler source files (in the \(fp)cmpnew\(fr) directory) should be processed in the same manner as library files in the \(fp)lsp\(fr) directory. The files \(fp)cmpmain.lsp\(fr), \(fp)cmpopt.lsp\(fr), and \(fp)lfun_list.lsp\(fr) should not be compiled. These three files are loaded by \(fp)init_kcl.lsp\(fr) (see below). The command \(fp)bin/cmpccall\(fr) compiles all the translated C source files in the \(fp)cmpnew\(fr) directory and attaches the corresponding data files. Or, you can use the makefile in the \(fp)cmpnew\(fr) directory. \(fp) % cd cmpnew % make \(fr) \(fp)cmpnew/cmpmain.lsp\(fr) defines the top-level of the compiler. Since this file contains the code to call the C compiler, it depends on the operating system. \(fg) 8. Raw System \(fr) The raw system (the KCL system without system initialization) is made by linking object files in the \(fp)o\(fr) directory object files in the \(fp)lsp\(fr) directory object files in the \(fp)cmpnew\(fr) directory \(fp)sys_kcl.o\(fr) in the \(fp)unixport\(fr) directory Not all the object files in the \(fp)lsp\(fr) directory have to be linked in the raw system. Only the following four files are necessary: \(fp) defmacro.o evalmacros.o module.o toplevel.o \(fr) Other library files are optional; they may be included in the system or loaded explicitly by the user, or made autoloaded. The compiler is also optional; you can make a system that does not include the KCL compiler. By default, all the library files and the compiler are included in the system. \(fp)sys_kcl.o\(fr) contains the initialization routine written in C. It is made by compiling \(fp)unixport/sys_kcl.c\(fr). Since the KCL system uses the "mathematical library" of C, the linkage editor should be invoked with the \(fp)-lm\(fr) option. The command \(fp)make_kcl\(fr) in the \(fp)unixport\(fr) directory compiles \(fp)sys_kcl.c\(fr) and links all the above object files with the C library, makes the raw system, initializes it, and saves the initialized system (see below). Or, you can use the makefile in the \(fp)unixport\(fr) directory. \(fp) % cd unixport % make \(fr) The raw system is named \(fp)raw_kcl\(fr) (in the \(fp)unixport\(fr) directory). You should change the current directory to \(fp)unixport\(fr) before issuing \(fp)make_kcl\(fr). \(fg) 9. Initialization \(fr) The initialization should be done in the \(fp)unixport\(fr) directory; you should change the current directory to \(fp)unixport\(fr). The raw system is invoked by typing \(fp) % raw_kcl. \(fr) After printing the banner and initializing the raw system, \(fp)raw_kcl\(fr) will output the prompt. \(fp) > \(fr) You are now at the toplevel. But the libraries and the compiler have not been initialized yet. The initialization of the library and the compiler is done by loading the file \(fp)unixport/init_kcl.lsp\(fr). \(fp) >(load "init_kcl") \(fr) After the initialization, the system is automatically saved in the file \(fp)saved_kcl\(fr) in the \(fp)unixport\(fr) directory, and \(fp)raw_kcl\(fr) is terminated. Here, to save the system means to dump the whole memory to an executable file (\(fp)saved_kcl\(fr) in this case). To change the configuration of the system, i.e., to change the set of library files to be included in the system, or to exclude the compiler, you should rewrite the following files. \(fp) sys_kcl.c init_kcl.lsp make_kcl \(fr) These files are all in the \(fp)unixport\(fr) directory. A utility called \(fi)defsystem\(fr) is prepared for changing the configuration of the system. It is written in KCL and is placed in the \(fp)unixport\(fr) directory (\(fp)defsystem.lsp\(fr)). Actually, the above three files were produced by defsystem. But you cannot use defsystem until you have installed KCL. Refer to the separate documents of defsystem for the details. The saved KCL system may be invoked by a command similar to the command in the command file \(fp)unixport/kcl\(fr). In \(fp)unixport/kcl\(fr), the full pathname of the saved system is specified to let the system know the pathname of itself; this is needed for the fasloader. The saved system may take several arguments. The first one is the pathname of the \(fp)unixport\(fr) directory (ending with '\(fp)/\(fr)'); it can be omitted if the saved system is in the \(fp)unixport\(fr) directory, and if there are no further arguments. Other arguments are specified when invoking the KCL compiler directly from the shell (by the command \(fp)unixport/lc\(fr) etc.). \(fg) 10. Hardware-Dependent Parts \(fr) In this section, we list those parts of KCL that depend on the hardware. Before that, we briefly point out those parts of the C source files of KCL that are influenced by the architecture of ECLIPSE/MV. ECLIPSE/MV is a word addressing machine; the byte pointer and the word pointer have different formats. Because of this peculiarity, the C source files contain many cast operators that may seem redundant for byte machines. For the UNIX BSD versions, we only assume byte addressing machines. The user's address space on ECLIPSE/MV begins with \(fp)0x7000000\(fr) (in word address); each address in the user's space has the ring number 7. The ring number should always be cleared to get the page number of the address. For the UNIX BSD versions, we assume that the address space begins with \(fp)0\(fr). \(fg) 10.1. Double-word Arithmetic and Bit-table Operation \(fr) \(fp)c/earith.c\(fr) contains some \(fp)asm\(fr) statements that define the double-word multiplication routine \(fp)extended_mul\(fr) and the double-word division routine \(fp)extended_div\(fr). Their formats are as follows. \(fp) extended_mul(d, q, r, hp, lp) int d, q, r; int *hp, *lp; \(fr) \(fp)d\(fr), \(fp)q\(fr), and \(fp)r\(fr) are positive integers (31 bits long). The result of \(fp)d*q+r\(fr), which is 62 bits long, is divided into two words each containing 31 bits and the high and low words are stored into \(fp)*hp\(fr) and \(fp)*lp\(fr), respectively. \(fp) extended_div(d, h, l, qp, rp) int d, h, l; int *qp, *rp; \(fr) \(fp)d\(fr), \(fp)h\(fr), and \(fp)l\(fr) are positive integers (31 bits long). \(fp)(h<<31)+1\(fr) is divided by \(fp)d\(fr) and the quotient and the remainder are stored into \(fp)*qp\(fr) and \(fp)*rp\(fr), respectively. \(fp)c/bitop.c\(fr) defines the bit-table operations used in the garbage collector to get or set a mark bit in the mark table. In the mark table, one bit is prepared for each word (1 word = 4 bytes). The top address of the mark table is stored in the C global variable \(fp)mark_table\(fr) (a pointer to \(fp)int\(fr)). The bit for a word pointer \(fp)x\(fr) is accessed by \(fp) (mark_table[x/4/32] >> (x/4%32)) & 1. \(fr) \(fp)c/bitop.c\(fr) defines three functions \(fp)get_mark_bit\(fr), \(fp)set_mark_bit\(fr), and \(fp)get_set_mark_bit\(fr), whose argument is a pointer to a word. \(fp)get_mark_bit\(fr) returns \(fp)0\(fr) or \(fp)1\(fr) according to whether the bit is off or on. \(fp)get_set_mark_bit\(fr) also returns \(fp)0\(fr) or \(fp)1\(fr), but sets the bit as \(fp)set_mark_bit\(fr) does. \(fg) 10.2. Floating Point Numbers \(fr) Some of the Common Lisp functions depend on the representation of floating point numbers; they include \(fp) decode-float scale-float float-radix float-digits float-precision integer-decode-float \(fr) In KCL, these functions are all defined in \(fp)c/num_co.c\(fr). Some floating point constants are also created in \(fp)c/num_co.c\(fr). You should look through the file \(fp)c/num_co.c\(fr) and change the code according to the representation of floating point numbers in your machine. The reader routine for floating point numbers does not depend on the hardware. As for the output, the C library function \(fp)sprintf\(fr) is used to get the mantissa and exponent of a floating point number. When the \(fp)IEEEFLOAT\(fr) switch is on, since the IEEE floating format is assumed, the exponent of a long floating point number can be three digits long. This affects the C function edit_double in \(fp)c/print.d\(fr). \(fg) 10.3. The C Stack \(fr) Usually, the C stack grows from the high core to the low core. But in some machines such as ECLIPSE/MV, it grows from the low to the high. The code to check whether the C stack has overflowed (or is about to overflow) depends on the direction that the C stack grows. In \(fp)c/main.c\(fr), the C global variable \(fp)cs_limit\(fr) is initialized; the initial value depends on the direction that the C stack grows. In the C function \(fp)eval\(fr) in \(fp)c/eval.c\(fr), \(fp)cs_limit\(fr) is compared with the address of the argument to check the C stack overflow. This also depends on the direction. \(fg) 10.4. Order of Arguments \(fr) The C functions \(fp)parse_key\(fr) (in \(fp)c/bind.c\(fr)), \(fp)list\(fr) (in \(fp)c/list.d\(fr)), and \(fp)listA\(fr) (in \(fp)c/list.d\(fr)) accept an arbitrary number of arguments. Usually, the first argument is placed in the lower address than other arguments, the second argument in the lower address than the rest, and so on. But in some machines such as ECLIPSE/MV, the order is reversed. \(fg) 11. Operating-System-Dependent Parts 11.1. Assembler File \(fr) The assembler file \(fp)c/char_table.s\(fr) (or \(fp)c/sun_chtab.s\(fr)) should be rewritten as explained in Section 5. \(fg) 11.2. Memory Management \(fr) The UNIX BSD versions of KCL use the \(fp)sbrk\(fr) system call to extend the process space. Heap manipulating functions provided as the standard library of C, such as \(fp)malloc\(fr) and \(fp)calloc\(fr), are not used. In fact, when calling \(fp)sbrk\(fr), KCL always checks whether the process' highest address has been changed after the last call of \(fp)sbrk\(fr). If the highest address has been changed, i.e., if some heap manipulating function has allocated memory, KCL reports a fatal error and exits immediately; KCL always wants to control the whole memory by itself. In the UNIX versions of KCL (except KCL/DGX), the following five library functions are redifined in \(fp)c/alloc.c\(fr); \(fp)malloc\(fr), \(fp)free\(fr), \(fp)realloc\(fr), \(fp)calloc\(fr) and \(fp)cfree\(fr). You should check whether the redefinition is compatible with other library functions. \(fg) 11.3. I/O \(fr) For I/O, KCL only uses the standard I/O library of C; it does not use any low-level system calls. You should only care about the deviation of the library of your machine from the standard I/O library of C. For example, the library of AOS/VS uses the name \(fp)_start\(fr) for the buffer address in the I/O buffer structure; in contrast, the library of UNIX uses the name \(fp)_base\(fr). Usually, the standard I/O library of C allocates the I/O buffer by calling \(fp)malloc\(fr). In KCL, \(fp)setbuf\(fr) is used to set the buffer to prevent the I/O library from calling \(fp)malloc\(fr). But in some cases, it is impossible to call \(fp)setbuf\(fr); for example, \(fp)getwd\(fr), which gets the current working directory, uses the standard I/O library to read directory files. To cope with those cases, the UNIX versions of KCL (except KCL/DGX) redefine \(fp)malloc\(fr) and the related functions (see Section 11.2); the redefined \(fp)malloc\(fr) allocates the I/O buffer in the standard heap of KCL. \(fg) 11.4. The Loader \(fr) Since the KCL compiler translates a Lisp program into a C program, KCL should have the facility to load the object file produced by the C compiler into the memory of the interpreter. The UNIX BSD versions of KCL invoke the standard linkage editor \(fp)ld\(fr) with the \(fp)-A\(fr) option (incremental loading) to relocate the object file. The interpreter then loads the output of \(fp)ld\(fr) into the memory. If \(fp)ld\(fr) in your machine does not have the facility of incremental loading, you should write the relocation routine by yourself. The code that calls \(fp)ld\(fr) and reads the output of \(fp)ld\(fr) is in \(fp)c/unixfasl.c\(fr). \(fg) 11.5. Memory Dump \(fr) The KCL function \(fp)save\(fr) saves the whole memory into an executable file. It is defined in \(fp)c/unixsave.c\(fr). It assumes the format of \(fp)a.out\(fr). \(fg) 11.6. The Compiler \(fr) \(fp)cmpnew/cmpmain.lsp\(fr) should be rewritten, if the code for the UNIX versions does not work. \(fg) 11.7. Miscellaneous \(fr) Programs in the following C files are OS-dependent: \(fp)unixfsys.c \(fr)file system interface \(fp)unixint.c \(fr)interrupt handling \(fp)unixsys.c \(fr)KCL function \(fp)system\(fr) \(fp)unixtime.c \(fr)time functions These files need not be changed when KCL is ported to machines running under UNIX BSD. But when porting KCL to machines running under UNIX System V, they will require several minor changes, depending on "the" System V. \(fg) 12. Site-Dependent Parts \(fr) \(fp)lsp/autoload.lsp\(fr) should be changed to setup site-dependent Lisp functions and variables. \(fp) lisp-implementation-type machine-type machine-version machine-instance software-type software-version short-site-name long-site-name *features* system:*default-time-zone* ed ... \(fr) You can also define other functions in \(fp)autoload.lsp\(fr), or set up storage parameters (by \(fp)allocate\(fr), \(fp)allocate-contiguous-pages\(fr), or \(fp)allocate-relocatable-pages\(fr)).